1. Field of the Invention
The present invention relates to the field of computer information directory operations. More specifically, embodiments of the present invention relate to the querying and updating of elements in a directory information tree, such as LDAP.
2. Related Art
A directory is like a database, but, in general, contains more descriptive, attribute-based information, such as a lists of employees within organizations that include telephone numbers and computer login IDs. Typically, information in a directory is read much more often than it is written. Hence, directories are tuned for high-volume lookup or search operations, with fast response times, but updating is still an important aspect of directory services. Directory information is typically distributed over many computers in order to increase availability and reliability, while reducing response time.
Directory services are currently provided by a variety of methods, the various methods addressing: how to store various kinds of information; how the information can be referenced, queried and updated; and how it is protected from unauthorized access, etc. Some directory services are local, providing service to a restricted context (e.g., the Unix “finger” service on a single machine). More complex services are global, providing service to a much broader context (e.g., the Internet). Global directory services are usually distributed, meaning that the data is spread across many machines, all of which cooperate to provide the directory service.
The most common global directory model currently in use is called LDAP, which stands for the Lightweight Directory Access Protocol. The present invention is described as an improvement over LDAP, but the present invention can be applied to any directory service. LDAP is a directory service protocol that runs over TCP/IP. The LDAP protocol, as recommended by the IETF, (found at http://www.ieff.org/internet-drafts/draft-ietf-Idapext-Idapjava-api-13.txt) has become a standard for directory operations.
The LDAP directory service model is based on entries. An entry is a collection of attributes, and a particular collection has a unique identifier called a “distinguished name” (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has an attribute name and one or more values. The attribute names are typically mnemonic strings, like “cn” for common name, or “mail” for email address. The values depend on the type of attribute. For example, an “mail” attribute might contain the value john@joe.com, while a “jpegPicture” attribute would contain a picture in binary JPEG format, or could be defined to be a pointer to a JPEG picture.
In a directory information tree, directory entries are arranged in a hierarchical tree-like structure that reflects political, geographic and/or organizational boundaries. For example, entries representing countries could appear at the top of the tree, closest to the root. Below countries, entries represent states or national organizations. Below those organizations, the entries could represent people, organizational units, printers, documents, or just about anything else.
FIG. 1 shows an exemplary directory information tree. FIG. 2 is an exemplary entry corresponding to one of the entries shown in FIG. 1, the entry shown as attributes paired with values. Each line in FIG. 2 is numbered for reference purposes, and each text-based figure in this specification has all of its lines numbered. FIG. 3 is an exemplary excerpt of prior art software source code for adding the entry of FIG. 2 to a directory information tree. At line 307, the DN for the entry is specified so as to describe the location within the directory information tree (of FIG. 1), this location being the list of branches taken from the root of the tree.
LDAP uses a directory information tree. In addition, LDAP allows you to control which attributes are required and allowed in an entry through the use of a special attribute called objectclass. The values of the objectclass attribute determine the schema rules the entry must obey.
An entry is referenced by its DN, which is constructed by taking the name of the entry itself (called the relative distinguished name, or RDN) and concatenating the names of its ancestor entries.
LDAP defines operations for interrogating and updating the directory. Operations are provided for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Most of the time, though, LDAP is used to search for information in the directory. The LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter. Information can be requested from each entry that matches the criteria.
For example, you might want to search the entire directory subtree below the level called “BigCorp” for people with the name “Edison”, retrieving the email address of each entry found. LDAP lets you do this easily, assuming you know how the directory information tree is structured. In this specification, structural information refers to any data that describes the branching of the directory information tree or attribute values that aid in directory operations.
LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the LDAP directory information tree. An LDAP client connects to an LDAP server and asks it a question. The server responds with the answer, or with a pointer to where the client can get more information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory. A name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service, like LDAP.
The database managers (where the directory information trees are stored) can be spread across many servers, and can run different types of database manager software.
A major shortcoming in current directory services is the need for application programs to specify an entire DN, requiring the application to “know” the structure of the directory information tree. For example, when an application adds an entry to a directory information tree, the destination location within the hierarchical structure of the directory information tree must be specified. As a specific example using LDAP, if an entry for “Tom Edison” needs to be added to a directory information tree (as shown in FIG. 1), a DN for the entry would be “uid=tedison, ou=employee, o=Big Corp, c=US” (as shown at line 307 in FIG. 3), and this must be specified by the application. If the structure of the directory information tree is changed, the application would probably need to be changed, too. Since rewriting applications is a significant cost and a source of possible errors, it would be highly advantageous to avoid the rewriting. It is the objective of the present invention to solve this major shortcoming.